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(g) Insertion of network data check sums by a network adapter. 

(S?) A method implements checksumming of a 
network packet (60) to be sent over a network 
(30). A processor (15) constructs the network 
packet (60) within a main memory (11) . The 
network packet (60) is transferred from the main 
memory (11) to a packet storage memory (44) 
within a network adapter (12). During the trans- 
fer, the network adapter (12) calculates a check- 
sum for the network packet (60). The network 
adapter (12) then inserts the checksum into the 
network packet (60) within the packet storage 
memory (44). The network adapter (12) then 
sends the network packet (60) to the network 
(30). In order to calculate the checksum for the 
network packet (60), hardware (42) within the 
network adapter (12) "snoops" an internal bus 
(49) within the network adapter (12) as the 
network packet (60) is transported to the packet 
storage memory (44). Also, a checksum header 
is prepended to the network packet (60) which 
includes control information for checksum- 
ming. This control information includes, for 
example, an indication whether the network 
adapter (12) is to calculate a checksum and a 
specification of what data in the network packet 
(60) is to be checksummed. The control infor- 
mation may additionally include a location with- 
in network packet (60) where the checksum is to 
b inserted. 
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Background 

The present invention concerns a hardware sys- 
tem which performs insertion of network data check- 
sums. 

5 

Most complex networks operate using several 
levels of protocol, each operating on a different layer 
of the network. For example, complex networks op- 
erating according to ISO OSI standard architecture in- 
clude a physical layer, a link layer, a network layer 10 
and a transport layer. See, Proceedings of the IEEE, 
Volume 71, No. 12, December 1983. 

The layers of protocol generally require various 
header fields to be included with data sent across a 
network. These header fields are variously used for 15 
such function as providing destination and source ad- 
dresses, assuring efficient data flow, and detecting 
and correcting errors in data transmission. Typically, 
significant processor time is spent in generating the 
header fields, deciphering the information in the 20 
header fields and copying data. 



Summary of the Invention 

In accordance with the preferred embodiment of 
the present invention, a method is provided for imple- 
menting checksumming of a network packet to be 
sent over a network. A processor constructs the net- 
work packet within a main memory. The network 
packet is transferred from the main memory to a 
packet storage memory within a network adapter. 
During the transfer, the network adapter calculates a 
checksum for the network packet. The network adap- 
ter then inserts the checksum into the network pack- 
et within the packet storage memory. The network 
adapter then sends the network packet to the net- 
work. 

In order to calculate the checksum for the net- 
work packet, hardware within the network adapter 
"snoops" an internal bus within the network adapter 
as the network packet is transported to the packet 
storage memory. Additionally, in the preferred em- 
bodiment, a checksum header is prepended to the 
network packet which includes control information for 
checksumming. This control information includes, for 
example, an indication whether the network adapter 
is to calculate a checksum and a specification of what 
data in the network packet is to be checksummed. 
The control information may additionally include a lo- 
cation within network packet where the checksum is 
to be inserted. 

For a network packet received from the network, 
the network adapter receives the network packet 
from the network, for example, into a packet storage 
memory. A transfer of the network packet is per- 
formed from the network adapter to the main mem- 
ory. During this transf r, th n twork adapter calcu- 
lat s a checksum for th n twork pack t. Th net- 



work adapt r app nds th checksum onto the net- 
work packet transf rred to the main memory. 

In order to calculat th checksum, hardware 
within the network adapter, snoops an internal bus 
within the network adapter as the network packet is 
transferred to the main memory. For an inbound net- 
work packet, checksum configuration information 
may be prepended to the beginning of a network 
packet. Alternately, checksum configuration informa- 
tion may be provided by the processor. The checksum 
configuration information includes, for example, an 
indication whether the network adapter is to calculate 
a checksum, and a specification of what data in the 
network packet is to be checksummed. 

The present invention allows the performance of 
checksumming without utilizing host processor time 
and without the degradation of performance of DMA 
transfers within the network adapter. 

Brief Description of the Drawings 



Figure 1 shows a blockdiagram which shows two 
computer systems connected to a network. 

Figure 2 shows data flow through a network in 
25 accordance with a preferred embodiment of the pres- 
ent invention. 

Figure 3, Figure 4, Figure 5 and Figure 6 show 
sample headers for messages sent in accordance 
with a preferred embodiment of the present invention. 
30 Figure 7 shows a block diagram of a network 

adapter in accordance with a preferred embodiment 
of the present invention. 

Figure 8 shows a header of a network packet sent 
to a network adapter in accordance with a preferred 
35 embodiment of the present invention. 

Figure 9 shows pad added to a packet construct- 
ed in memory in accordance with a preferred embodi- 
ment of the present invention. 

Figure 10 is a simplified diagram showing a net- 
40 work adapter receiving a network packet from a host 
in accordance with a preferred embodiment of the 
present invention. 

Figure 11 is a simplified diagram showing a 
checksum being added to a network packet in accor- 
45 dance with a preferred embodiment of the present in- 
vention. 

Figure 12 is a simplified diagram showing a net- 
work packet being received by a network adapter 
from a network in accordance with a preferred em- 
50 bodiment of the present 

Figure 13 shows a network packet stored in a 
main memory in accordance with a preferred embodi- 
ment of the present invention. 

Figure 14 is a simplified diagram showing a net- 
55 work packet being sent by a network adapter to a host 
system in accordance wit h a pref rred mbodiment of 
thepres nt invention. 

Figur 15 shows a block diagram of a checksum 
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logic cell array in accordance with the preferred m- 
bodiment of the pres nt invention. 

Description of the Preferred Embodiment 



network adapt r 12 inserts th ch cksum into th 
proper location within th packet before transmitting 
the pack t on n twork 30. 
5 In the inbound direction, network adapter 12 de- 

codes the packet header and programs the check- 
sum control information directly into internal regis- 
ters. The network adapter 12 calculates the check- 
sum as it transfers the packet to memory 11. When 
the network adapter 12 completes the calculation of 
the checksum, network adapter 12 appends the re- 
sult to the data stream that is being transferred to the 
memory 11. The processor 15 compares this check- 
sum result against the packet checksum to verify the 
data. 

The second operation which the network adap- 
ters performs is the automatic separation of headers 
and data during the transfer of incoming packets from 
network adapter 12 to memory 11. Splitting the head- 
er and data during the transfer allows the data to be 
placed on a page aligned boundary in host memory. 
Memory pages can be delivered to the proper appli- 
cation by virtual page remapping. This process is ac- 
complished by simple virtual pointer manipulation and 
eliminates the need to copy the data once the packet 
has been transferred to memory 11 by network adap- 
ter 12. 

Network adapter 12 determines the location of 
the header/data split and programs the DMA hard- 
ware with this value. The DMA hardware counts down 
the bytes of the header until the split location is 
reached. By adding pad data, the DMA hardware as- 
sures that the beginning of the data portion of the 
packet will fall on a memory page boundary. This 
process is run in parallel with the checksum process 
described above. 

The third operation which network adapter 12 
performs is the alignment of network headers. This 
is accomplished by the insertion of pad bytes based 
on specific values found in the network link header. 
Many processors are unable to access multi-byte 
fields which are not aligned to the corresponding mul- 
ti-byte boundary. A processor would have to copy the 
bytes to an auxiliary buffer to access the data. Net- 
work adapter 12 eliminates the need for this copy. 

Network adapter 12 searches the incoming byte 
stream for specific values in the destination SAP 
(DSAP) field of the network link header. The hard- 
ware will insert between 0 and 3 pad bytes between 
the destination SAP and source SAP fields based on 
the value found in the destination SAP field. Subse- 
quent headers will then be 4-byte aligned in the data 
stream. 

Figures 3 through 6 show sample headers for 
messages sent in accordance with a preferred em- 
bodiment of the present invention. Figure 3 shows an 
FDDI snap header 110 before the ins rtion of DSAP 
pad bytes. Media header 110 includes a one byte 
fram control (FC) fi Id 111. Asix-byt d stination ad- 



Figure 1 is a simplified block diagram which 
shows a computer system 1 0 connected to a comput- 
er system 20 over a network 30. Computer system 1 0 
includes a processor 15, a cache 14, a memory 11 u 
and a network adapter 1 2. A memory bus 1 3 con nects 
processor 15 (through cache 14), memory 11 and 
network adapter 12. Network adapter 12 serves as 
an interface to network 30. Computer system 20 in- 
cludes a processor 25, a cache 24, a memory 21 and n 
a network adapter. A memory bus 23 connects proc- 
essor 25 (through cache 24), memory 21 and net- 
work adapter 22. Network adapter22 serves as an in- 
terface to network 30. The present invention con- 
cerns performance of the network data to simplify 20 
the assembly and deciphering of header fields for 
data which is sent across network 30. 

Figure 2 shows data flow of a message which is 
transferred across network 30. A data path 51 and a 
data path 52 represent the flushing (or writing 25 
through) from cache 14 to memory 11 any information 
in cache 14 which will be used as part of the header 
or data forming the message. A data path 53 repre- 
sents a DMA transfer operation from memory 11 to 
network adapter 12. A data path 54 represents data 30 
flow across network 30. A data path 55 represents a 
DMA transaction from network adapter 22 to memory 
21. A data path 56 and a data path 57 represents an 
invalidation of memory locations within cache 24 
which contain data made stale by the DMA transac- 35 
tion from network adapter 22 to memory 21. 

In order to achieve the simplified data path for 
messages, network adapter 12 and network adapter 
22 perform three operations normally performed by 
processor 1 5 and processor 25, respectively. The fol- 40 
lowing discussion sets out how these operations are 
performed by network adapter 12; however, since 
network adapter 12 and network adapter 22 are iden- 
tical in performance, the discussion equally applies to 
the operation of network adapter 22. 45 

The first operation is the generation and insertion 
of network data checksums by network adapter 12. 
The implementation of the checksum calculation by 
network adapter allows the generation and insertion 
of the checksum with virtually no added overhead or 50 
time incurred by processor 15. 

In the outbound direction, processor 15 provides 
network adapter 12 checksum control information 
which indicates the proper method of checksumming 
and the location to insert the result. This control infor- 55 
mation is prepended to the packet in the DMA data 
stream trav ling along data path 53. As the data is 
transferred from memory 1 1 , n twork adapter 1 2 cal- 
culates the ch cksum. When the transfer is compl te, 
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dress field 112 giv s the m dia address of a station 
receiving the packet. A six-byte source addr ss field 
1 1 3 giv s th media address of a station s nding th 
packet 5 

A one byte Destination Service Access Point 
(DSAP) field 114 defines the type of service being 
used and therefore the format of the media header. 
If DSAP equals AA^ then media header 110 is a 
SNAP header and three bytes of pad will be inserted 10 
after DSAP field 114. If DSAP equals FC^, media 
header 1 1 0 is an HP expansion SAP and one pad byte 
will be inserted after DSAP field 114. In the present 
invention all other DSAP values result in the insertion 
of no pad bytes. This is because other headers, for ex- is 
ample, an FDDI 802.2 header, do not require addition- 
al pads to be inserted. 

A one byte SSAP field 116 contains the source 
service access point. LLC 802.2 Type 1 Control 
(CTRL) field 117, in the preferred embodiment, is al- 20 
ways set to 3 which indicates unnumbered informa- 
tion. A three byte organization ID field 118 is not proc- 
essed by the preferred embodiment of the present in- 
vention. A two byte SNAP type field 119 is not proc- 
essed by the preferred embodiment of the present in- 25 
vention. 

After the above-described fields of the link head- 
er, an IP header 120 is followed by a TCP header or 
a UDP header. IP header 120 is twenty or more bytes 
in length. A TCP header is twenty or more bytes in 30 
length. A UDP header is eight bytes in length. 

In order to align the headers, the preferred em- 
bodiment of the present invention inserts between 0 
and 3 pad bytes between DSAP field 114 and SSAP 
field 116, based on the value found in the DSAP field. 35 
Subsequent headers will then be 4 byte aligned in the 
data stream. In media header 110, DSAP equals AA^x 
indicating media header 110 is a SNAP header. 
Therefore, three bytes of pad 115 are inserted after 
DSAP field 114, as shown in Figure 4. 40 

Figure 5 shows an FDDI HP expansion header 
130 before the insertion of a DSAP pad byte. Media 
header 130 includes a one byte frame control (FC) 
field 131. A six-byte destination address field 132 
gives the media address of a station receiving the 45 
packet A six-byte source address field 133 gives the 
media address of a station sending the packet. 

A one byte Destination Service Access Point 
(DSAP) field 134 defines the type of service being 
used and therefore the format of the media header. so 
DSAP equals FC^, indicating media header 130 is 
an HP expansion SAP and one pad byte will be insert- 
ed after DSAP field 134. A one byte SSAP field 136 
contains the source service access point LLC 802.2 
Type 1 Control (CTRL) field 137, in the preferred em- 55 
bodim nt, is always set to 3 which indicates unnum- 
ber d information. At hre byte HP xpansion service 
access point (XSAP) spacing f i Id 1 38 is reserved. A 
two-byt destination xpansion service access point 



(DXSAP) f i Id 1 39 and a two-byte source xpansion 
service access point (SXSAP) field 140 are utiliz d as 
part of a particular protocol. 

After the above-described fields of the link head- 
er, an IP header 141 is followed by a TCP header or 
a UDP header. 

In order to align the headers, the preferred em- 
bodiment of the present invention inserts a pad byte 
between DSAP field 134 and SSAP field 136, based 
on the value found in the DSAP field. Subsequent 
headers will then be 4-byte aligned in the data 
stream. In media header 130, DSAP equals FC hex in- 
dicating media header 130 is an HP expansion SAP 
header. Therefore, a single pad byte 135 is inserted 
after DSAP field 134, as shown in Figure 6. 

Figure 7 shows a block diagram of a portion of 
logic used to implement network adapter 12 in accor- 
dance with the preferred embodiment of the present 
invention. Network adapter 12 is connected to a back- 
plane DMA controller 31 of computer system 10 
through a backplane bus 33. Backplane DMA control- 
ler 31 performs DMA between memory 11 and net- 
work adapter 12. 

Network adapter 12 is connected to network 30 
through a front plane controller 32. For example, in 
the preferred embodiment, network 30 is an FDDI 
network and frontplane controller 32 is a LAN control- 
ler such as a LAN Controller DP83261 , available from 
National Semiconductor Corporation, a California 
corporation having a place of business at 2900 Sem- 
iconductor Drive, Santa Clara, California 95051. 

Afrontplane logic cell array (LCA) 45 serves to re- 
ceive data from and send data to network 30 via front- 
plane controller 32. LAN controller 32 provides trans- 
mission and reception of data packets to and from 
network 30. 

For outbound transfers, frontplane LCA 45 un- 
packs the 32 bit words from a DMA bus 49 into 8 bit 
bytes for transmission by LAN controller 32. Front- 
plane LCA 45 also looks at the first byte of the output 
stream, which contains a count of how many FC pad 
bytes have been inserted by processor 15, and then 
strips off the FC pad bytes and sends the rest of the 
packet to LAN controller 32. Frontplane LCA 45 loads 
an outbound first- in-first-out memory (FIFO) with 
data for transmission. Frontplane LCA 45 then con- 
trols the handshake with LAN controller 32 for trans- 
mission of the packet. 

For inbound transfers, frontplane LCA 45 hand- 
shakes data into an inbound FIFO, while watching the 
status lines from LAN controller 32 for error conditions 
which would force a flush of the incoming packet. 
Frontplane LCA 45 takes the byte stream from LAN 
controller 32 and packs it into a 32 bit word stream for 
DMA bus 49. While frontplane LCA 45 packs the data 
stream, it also k eps track oft h length of th packet 
being receiv d and ins rts this length as part of th 
pack t status at the nd of th packet. Frontplan 
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LCA45als scans the input str am for the DSAPfi Id 
to determine what type of padding will be required to 
force th remaining headers and data to b aligned. 
Upon finding the DSAP field, frontplane LCA45 in- 
serts 0-3 bytes of DSAP pad. When frontplane LCA45 
detects the end of the packet, by sensing the 
EDRCVD line, it will insert the status of the packet, as 
sensed from LAN controller 32, and the length of the 
packet It will insert 0-3 bytes of pad to insure that the 
status and length are contained in a single 32 bit 
word. The length field will not include the number of 
bytes padded to align the status and length word, the 
SLLW, or the checksum result added by checksum 
LCA42. 

A backplane logic cell array (LCA) 41 serves to 
receive data from and send data to memory bus 13 
through backplane DMA controller 31. 

A DMA bus 49 is separated from a processor bus 
38 by a latch 46. A central processing unit (CPU) 37, 
a random access memory (RAM) 36, a nonvolatile 
RAM (NOVRAM) 35 and a read only memory (ROM) 
34 are connected to processor bus 38. For example 
processor bus 38 is 32 bits wide. CPU 37 is a 68020 
processor with a processor clock speed of 25 mega- 
hertz (MHz) available from Motorola Communications 
and Electronics Inc., having a business address at 
801 Ames Avenue, Milpitas, California. CPU 37 is 
used to provide selftest functionality, chipset control 
of the frontplane (e.g. for initialization), connection 
management of the FDDI link, and other various func- 
tions. The code for the CPU 37 is contained in ROM 
34. At startup, the CPU 37 will copy the code to RAM 
36 and then execute the code from there. This will al- 
low CPU 37 to execute wit h zero wait state instruction 
cycles. 

Achecksum logic cell array (LCA) 42, a DMAcon- 
trol logic cell array (LCA) 43 and a slot memory 44 are 
connected to DMA bus 49. 

DMA bus 49, together with checksum LCA 42, 
DMA control LCA 43, backplane LCA 41 and slot 
memory 44 function as a data pipe to move data be- 
tween LAN controller 32 and backplane DMA control- 
ler 31 with high throughput and low latency. The data 
pipe also provides the checksum hardware assist and 
manipulates the data to correct for improper align- 
ment of headers, data, and buffers. A side feature is 
that the data pipe provides restricted access to the 
data stream by CPU 37 and does so with little effect 
on transfer performance. 

Slot memory 44 is a block of fast static RAM that 
is designed to provide a bandwidth of 50 Mbytes/sec. 
This bandwidth is shared between LAN controller 32, 
backplane DMA controller 31, and CPU 37 by time di- 
vision multiplexing. Access to slot memory 44 is con- 
trolled entirely by DMA controller LCA 43. Slot mem- 
ory 44 is logically divided into 8K byte (enough for a 
maximum sized FDDI packet) slots into which packets 
are deposit d. The slot concept provides a simple 



method of memory management 

The main function of DMA controller LCA 43 is to 
manage slot m mory 44. DMA c ntroll rLCA43ac- 

s cepts requests for data transfers wit h slot memory 44 
and then generates the addresses and data strobes 
necessary to move data to the proper client. No other 
device has direct access to slot memory 44. This 
method of memory management guarantees all ac- 

10 cesses are short and no device will hold up another. 

DMA controller LCA 43 provides two DMA chan- 
nels, one for transfers with backplane DMA controller 
31 and one for transfers with LAN controller 32. DMA 
controller LCA 43 also acts as a proxy for access by 

15 CPU 37 to slot memory 44. DMA controller LCA 43 
has a CPU address register, that CPU 37 can load, 
which is used when CPU 37 requests access to slot 
memory 44. When CPU 37 requests data, DMA con- 
troller LCA 43 fetches data from the location pointed 

20 to by the CPU address register and latches it into latch 
46 for later access by CPU 37. DMA controller LCA 43 
also has another address registerthat is used to allow 
checksum LCA 42 to insert a checksum into an out- 
bound packet 

25 Checksum LCA 42 snoops data bus 49 during 

data transfers and calculates a checksum as data is 
being moved to/from backplane DMA controller 31 
from/to slot memory 44. In order to perform the 
checksum operation, the various parameters of the 

30 checksum must first be programmed into the check- 
sum LCA 42. This is accomplished by inserting the 
configuration into the data stream. 

Checksum LCA 42 is configured with a Check- 
sum Type (None, TCP, UDP), a Checksum Start Off- 

35 set, a Checksum Stop Offset and a Checksum Insert 
Offset (used only for outbound data packets). All the 
checksum offset parameters are BYTE offsets of the 
packet 

In the preferred embodiment of the present in- 

40 vention, checksum LCA 42 handles on lyARPA servic- 
es. Checksum LCA 42 will correctly handle a start and 
stop offset that is any arbitrary byte of feet. This can 
be done because of the simple nature of the ARPA 
checksums, but for other checksums (i.e. OSI) this 

45 may not be sufficient 

The Checksum Stop Offset value must be the ex- 
act offset where checksumming must stop. If the 
checksum is to run to the end of the packet it still 
must have the exact offset. Checksum LCA 42 will 

so stop checksumming if the end of packet (EOP) bit is 
reached, but checksum LCA 42 will not know if all the 
bytes of the word are valid and it will assume that they 
are. Therefore, some garbage bytes may be included 
in the checksum if the stop offset is not exact. 

55 Figure 15 shows a block diagram of checksum 

LCA 42. A type and status register 186 stores the 
checksum typ .Astartoffs t register 187 stores th 
start of fs t A stop offset register 188 stor sth stop 
offe t. An insert offset register 189 stores the ins rt 
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offset. A checksum accumulator 182 calculat s the 
checksum of the data stream on DMA bus 49. A 
ch cksum is stored in a checksum regist r 184. A mul- 
tiplexor 183 selects the results of checksum accumu- s 
lator 182 or a value on DMA bus 49 to be placed in 
checksum register 184. A latch 185 is used to latch 
checksum 184 onto DMA bus 49. A control 181 con- 
trols operation of checksum LCA42. In the block dia- 
gram shown in Figure 15 shows only a single check- 10 
sum accumulator, additional checksum accumulators 
may be added in order to accommodate different 
checksumming algorithms. These may be multi- 
plexed to checksum register 184. 

Backplane LCA 41 is used to handshake data 15 
with backplane DMA controller 31, pack and unpack 
data, and provide proper alignment of the data trans- 
ferred through backplane DMA controller 31. 

The following describes an outbound transfer 
with checksum insertion. In the preferred embodi- 20 
ment, network adapter 1 2 is always in a read pending 
state. This allows an inbound packet to get to proces- 
sor 15 quickly. Because of this, processor 15 must 
first notify network adapter 12 that an outbound 
transfer is coming so that network adapter 1 2 can get 25 
set up to accept it. Also, since the outbound packet is 
to have a checksum inserted into the data stream, the 
packet must not be transmitted until the checksum 
has been inserted. This forces the outbound packet 
to be staged in slot memory 44 until the checksum 30 
process is complete. 

The following describes what must be done in or- 
der to insert a checksum and send an outbound pack- 
et. The outbound packet must be built in memory 11. 
Processor 1 5 must prepend an appropriate checksum 35 
control header to the packet. 

For example, Figure 8 shows an outbound packet 
60 built in memory 11. Outbound packet 60 includes 
a checksum control header 61 , a link level header 62, 
an IP header 63, a transport header 64 and user data 40 
65. Checksum control header is shown to include a 
start offset field 71 , a stop offset field 75, an algo field 
72, a direction field 73, an insert field 74 and an insert 
offset field 76. Start of fset field 71 indicates the byte 
at which checksumming is to start. Stop offset field 75 45 
indicates the stop offset, that is, the number of bytes 
which are to be checksummed. Algo field 72 indicates 
the checksum algorithm used (TCP, UDP, etc.). Direc- 
tion field 73 indicates the direction of data flow (in- 
bound or outbound). Insertf ield 74 indicates whether 50 
the outbound packet is to have a checksum inserted. 
Insert offset field 76 indicates the location where a 
checksum is to be inserted. 

Figure 9 shows how FC pad bytes 160 may be 
added in memory 11 to align the headers along multi- 55 
byte boundaries, for example, along 16 byte boundar- 
ies. In Figure 9, Link level header 62 includes a n 
byt frame control (FC) field 1 61 , six-byte destination 
address field 162, a six-byte source address fi Id 



163, a one byte Destination S rvice Access Point 
(DSAP) field 164, a one byte SSAP field 166, a Con- 
trol (CTRL) field 167 and th rfi Ids (not shown). In 
order to allow alignment of the headers for DMA, FC 
pad bytes are added before FC field 161. An FC pad 
count field 1 59 indicates the number of FC pad bytes 
added. 

The use of FC pads allows the networking proto- 
col software operating on processor 15 to build its 
headers in main memory 11, without forcing the link 
header to fall on a particular multi-byte boundary. 
Generally, headers are built from back to front. The 
first byte of the header, therefore, is not necessarily 
aligned on any particular byte boundary. In the prior 
art, when a header was not properly aligned for DMA 
out of main memory 11, it would be necessary to copy 
the header before DMA to network adapter 1 2. In the 
preferred embodiment of the present invention, the 
first bytes of a DMA transfer are the FC count which 
signals the number of FC pad bytes which precede 
the header in order to allow the DMA to start at an 
aligned (i.e. cache line boundary) location. Additional 
FC pad bytes are added so that DMA transfer begins 
on a sixteen byte boundary. 

Once the outbound packet is built in memory 11, 
backplane DMA controller 31 starts to move data from 
memory 11 to network adapter 12. DMA controller 
LCA 43 moves the data from backplane LCA 41 to slot 
memory 44, except for the checksum control 61, 
which contains configuration data for checksum LCA 
42 and DMA controller LCA 43. 

DMA controller LCA 43 must check insert field 74 
of checksum control header 60 to determine if the 
packet is to have a checksum inserted or not. In the 
case where a checksum is to be inserted, outbound 
packet 60 packet must be stored in slot memory 44 
until the checksum is inserted. This is illustrated by 
Figure 10. 

While DMA controller LCA 43 moves the data 
from backplane LCA 41 to slot memory 44, checksum 
LCA 42 snoops the data on DMA bus 49, checksum- 
ming the data as it goes by. In the preferred embodi- 
ment, a sixteen bit add with carry is used. The check- 
summing starts at the byte designated by start offset 
field 71 and continues until either the stop offset is 
reached or the end of packet (EOP) bit is sensed. 
Checksum LCA 42 mask off bytes that are not part of 
the checksum. This allows checksumming to start 
and stop on arbitrary byte boundaries. This works fine 
for ARPAservices, but some modification to the algo- 
rithm will be needed for other types of checksum. 

When the last word of data is latched by back- 
plane LCA 41, as indicated by backplane DMA con- 
troller 31, backplane LCA 41 so signals to checksum 
LCA 42. Upon receipt of the signal, checksum LCA 42 
asserts a ch cksum valu 77 on data bus 4g and sig- 
nals DMA controller LCA 43 to write checksum value 
77 into slot memory 44 at th offe tgiv n in ins rtoff- 
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set field 76. This is illustrated by Figure 11. Also upon 
d tectingth end of the packet, backplane DMA con- 
troller 31 int rrupts processor 15. If process r 15 is 
done with outbound transfers, processor 15 posts a 
read to network adapter 12. If processor 15 wishes to 
do another outbound transfer, processor 1 5 proceeds 
with the next outbound transfer. 

Once checksum value 77 is written into slot mem- 
ory 44, DMA controller LCA 43 starts to move data 
from slot memory 44 to LAN controller 32 for transmis- 
sion to network 30. Frontplane control LCA 45 un- 
packs the 32-bit data stream into an 8 bit data stream. 
This data stream contains a Frame Control byte and 
the preceding FC pad bytes. Frontplane control LCA 
45 will strip off the FC pad bytes and send the remain- 
der of the data stream to LAN controller 32. 

An outbound transfer may also be sent without a 
checksum insertion. Since this outbound packet 
won't have to insert a checksum, the packet can be 
immediately streamed to LAN controller 32 for trans- 
mission. The lack of an insertion of a checksum does 
not mean that a checksum cannot be calculated for 
the packet. For example, if an IP fragment train is be- 
ing processed, the first N packets will have a running 
checksum calculated and only the N+1 packet will 
have the total checksum inserted into it. The first N 
packets can be immediately streamed to LAN control- 
ler 32. 

The following process is done to receive an in- 
bound packet. The inbound packet starts arriving in 
LAN controller 32. LAN controller 32 signals front- 
plane LCA 45 that data is arriving. Frontplane control 
LCA 45 clocks the data into a buffer within frontplane 
control LCA 45. When the number of bytes received 
exceeds a fixed threshold, a signal is given to DMA 
controller LCA 43 to start moving data into slot mem- 
ory 44. 

Figure 12 illustrates an inbound packet 80 being 
moved into slot memory 44. As data is moving into slot 
memory 44, frontplane LCA 45 is looking for the 
DSAP field within the inbound packet. Once found, 
thefrontplane LCA 45 inserts pad bytes, based on the 
value of the DSAP, to align the data and header por- 
tion of the packet. 

After the pad bytes are inserted, DMA controller 
LCA 43 moves the remainder of the data to slot mem- 
ory 44. When the end of the packet is reached, front- 
plane LCA 45 will append the status bits from LAN 
controller 32 and the length of the packet to the end 
of the data stream. Frontplane LCA 45 will also force 
the status/length word to be long word aligned by ap- 
pending leading pads. It will assertthe EOP bit on the 
last byte of the status/length word. 

DMA controller LCA 43 moves the data into a slot 
in slot memory 44. When the number of bytes moved 
xce ds a fixed threshold, for exampl 32 bytes, an 
interrupt is giv n to CPU 37 to signal that it can start 
reading the head r from slot m mory 44. CPU 37 will 



analyze th header to determine the checksum typ , 
start and stop offsets. The CPU will also determin 
wh retoseparat th h ader from data. 
5 DMA controller LCA 43 has a counter which 

keeps track of the number of pending packets waiting 
to be analyzed by CPU 37. 

CPU 37 analyses the header and writes the 
header/data split and the checksum information to 
10 slot memory 44 using the CPU address register with- 
in DMA controller LCA 43. If the checksum type is 
NONE, the start and stop fields are ignored and do 
not need to be written. 

The first 3 words of the transfer are not given to 
15 backplane LCA41 , but are latched by checksum LCA 
42 to load the checksum configuration for the current 
inbound packet 

The next word is loaded by backplane LCA 41 into 
an internal split offset counter within backplane LCA 
20 41 , as well as passing it on as data to processor 1 5. 
This internal split offset count is based on the header 
buffer length and is used to determine when the 
header has been sent to processor 15 and when to 
start padding data bytes to fill out the first buffer on 
25 the data chain. 

Backplane LCA 41 unpacks the 32 bit data 
stream from midplane bus 49 into a 16 bit data stream 
for transfer to backplane DMA controller 3 1 . It will con- 
tinue to do this until it senses the End-Of-Packet 
30 (EOP) bit, which ends the DMA transfer. 

The DSAP pads help insure that the header/data 
split is on a four-byte boundary, so it will not be nec- 
essary to handle odd byte alignments. If CPU 37 de- 
termines that the header/data split is not on an even 
35 byte boundary, the inbound packet must be transfer- 
red to memory anyway, and the alignment must be 
corrected by processor 15. If backplane LCA 41 de- 
tects an odd split offset, it will set an error indication 
in a status register accessible by processor 15. 
40 As data is sent to memory 1 1 , backplane LCA 41 

decrements the split offset count and the header buf- 
fer length count. The header buffer length count is ini- 
tialized to the number of bytes in a memory buffer. 
When the split offset count reaches zero, backplane 
45 LCA 41 will start sending pad data and decrementing 
a header buffer length count until it reaches zero. This 
serves to fill up the first buffer which is designed to 
contain only the header. At this time, backplane LCA 
41 resumes sending data from slot memory 44. This 
50 will be the data payload which will end up being page 
aligned. In an alternate preferred embodiment, when 
the split offset count reaches zero, backplane LCA 41 
will start sending data to a next memory buffer with- 
out sending pad data. This alternate embodiment al- 
55 lows more efficient transfers, and is preferred when 
the backplane DMA controller is able to implement it. 

Figure 13 illustrates th r sultant alignment in 
memory 11. In memory 11, ah ad r buffer 91 , a data 
buffer 92 and a data buffer 93 ar shown. Header buf- 
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fers are a small porti n of m mory. Data buffers 92 
and 93 each r pres nt a single pag of memory 11. 
For xampl , each page of m mory includes 2048 
bytes of data. In order to assure that data is page s 
aligned, pad data 102 is added after a packet header 
1 01 to fill up header buffer 91 . This assures that pack- 
et data 1 03 is placed beginning in data buffer 92. Ad- 
ditional packet data 104 may be placed in a following 
data buffer 93, if necessary. 10 

When the last word of the data is latched into 
backplane LCA41 , the EOP bit wilt be set This word 
is the Status Length Long Word (SLLW). Backplane 
LCA41 now looks to see if this last 32 bits of data will 
be on an 8 byte boundary in memory 11. If not, it will 15 
send pad bytes to force this alignment This assists 
processor 15 in finding the status and checksum in- 
formation quickly. The SLLW will then be sent. 

After backplane LCA 41 sends the SLLW, back- 
plane LCA41 will read in one more word from the pi- 20 
peline data bus, which contains a checksum result 87. 
This is represented by Figure 14. Checksum result 87 
is transferred to backplane DMA controller 31 with a 
signal that the DMA transfer is complete. This termin- 
ates the DMA transfer and backplane DMA controller 25 
31 will generate an interrupt to processor 15 signaling 
the DMA transfer completion. Processor 15, upon in- 
terrupt, reads a status register within backplane LCA 
41, which indicates the length (in words) of the in- 
bound transfer. The status register will also indicate if 30 
any errors occurred on network adapter 12 and 
whether buffers exist on network adapter 12 to do 
more inbound or outbound processing. 

The foregoing discussion discloses and de- 
scribes merely exemplary methods and em bod i- 35 
ments of the present invention. As will be understood 
by those familiar with the art, the invention may be 
embodied in other specific forms without departing 
from the spirit or essential characteristics thereof. Ac- 
cordingly, the disclosure of the present invention is in- 40 
tended to be illustrative, but not limiting, of the scope 
of the invention, which is set forth in the following 
claims. 



storage m mory (44) within the n twork 
adapter (12), including the substep of: 

(b.1) calculating, by the network adap- 
ter (1 2), of a checksum for the network packet 
(60) during transfer of the network packet 
(60); 

(c) inserting, by the network adapter (12), the 
checksum into the network packet (60) within 
the packet storage memory (44); and, 

(d) transferring, by the network adapter (12), 
the network packet (60) to the network (30). 

2. A method as in claim 1 wherein step (b.1) in- 
cludes snooping, by hardware (42) within the net- 
work adapter (12), of the network packet (60) as 
the network packet (60) is transported over an in- 
ternal bus (49) within the network adapter (12) to 
the packet storage memory (44). 

3. A method as in claim 1 wherein step (b) includes 
the substep of prepending to the network packet 
(60) a checksum header which includes control 
information for checksumming. 

4. In a computing system (10) connected to a net- 
work (30), the computing system (10) including a 
main memory (11) and a network adapter (12), a 
method for implementing checksumming of a net- 
work packet (80) received from the network (30), 
the method comprising the steps of: 

(a) receiving, by the network adapter (12), the 
network packet (80) from the network (30); 

(b) performing a transfer of the network pack- 
et (80) from the network adapter (12) to the 
main memory (11), including the substep of: 

(b.1) calculating, by the network adap- 
ter (1 2), of a checksum for the network packet 
(80) during transfer of the network packet 
(80); and, 

(c) appending, by the network adapter (12), 
the checksum onto the network packet (80) 
transferred to the main memory (11). 



45 



Claims 



1. In a computing system (10) connected to a net- 
work (30), the computing system (10) including a 
processor (15), a main memory (11) and a net- so 
work adapter (12), a method for implementing 
checksumming of a network packet (60) sent 
over the network (30), the method comprising 
the steps of: 

(a) constructing, by the processor (15), the 55 
network packet (60) within the main memory 
(11): 

(b) performing a transfer of the n twork pack- 
t(60)fromth main memory (11) to a pack t 

8 



5. A method as in claim 4 wherein step (b.1) in- 
cludes snooping, by hardware (42) within the net- 
work adapter (12), of a network adapter internal 
bus (49) as the network packet (80) is transferred 
from the network adapter (12). 

6. A method as in claim 4 wherein the checksum 
configuration information includes an indication 
whether the network adapter (12) is to calculate 
a checksum, and a specification of what data in 
the network packet (80) is to be checksummed. 

7. In a computing system (10) conn cted to a net- 
work (30), the computing system (10) including a 
processor (15) and a main memory (11), a net- 



15 



EP 0 572 146 A2 



work adapt r (12) comprising: 
a DMA bus (49); 

a packet storag means (44), coupled to 
the DMA bus (49), for storing network packets 5 
(60, 80); 

DMA means (43), coupled to the DMA bus 
(49), for performing a transfer of a network pack- 
et (60, 80) between the main memory (11) and 
the packet storage means (44); 10 

checksum calculating means (42), cou- 
pled to the DMA bus (49), for calculating a check- 
sum for the network packet (60, 80) during trans- 
fer of the network packet (60, 80), the checksum 
calculating means (42) including: 15 

snooping means (182) for monitoring data 
transported on the DMA bus (49). 

8. A network adapter (12) as in claim 7 wherein the 
checksum calculating means (42) additionally in- 20 
eludes: 

insertion means (184, 185) for inserting a 
calculated checksum into a network data packet 
stored in the packet storage means (44). 

25 

9. A network adapter (12) as in claim 7 wherein the 
checksum calculating means (42) additionally 
comprises control information storage means 
(1 86, 1 87, 1 88, 1 89) for storing checksum control 
information prepended to a network packet (60, 30 
80). 

10. A network adapter (12) as in claim 9 wherein the 
checksum control information includes an indica- 
tion whether the network adapter (12) is to cal- 35 
culate a checksum, and a specification of what 
data in the network packet (60, 80) is to be check- 
summed. 
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